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PPP Predictor Compression Protocol 
Status of This Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method of 
encapsulating multiple protocol datagrams over point-to-point links. 


The PPP Compression Control Protocol [2] provides a method for 
transporting multi-protocol datagrams over PPP encapsulated links. 


This document describes the use of the Predictor data compression 
algorithm for compressing PPP encapsulated packets. 
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1. Introduction 


Predictor is a high speed compression algorithm, available without 
license fees. The compression ratio obtained using predictor is not 
as good as other compression algorithms, but it remains one of the 
fastest algorithms available. 


Note that although care has been taken to ensure that the following 
code does not infringe any patents, there is no assurance that it is 


Rand Informational [Page 1] 


RFC 1978 


Predictor Protocol 


not covered by a patent. 


2. Licensing 


August 1996 


There are no license fees or costs associated with using the 
Predictor algorithm. 


Use the following code at your own risk. 


3. Predictor Packets 


Before any Predictor packets may be communicated, PPP must reach the 


Network-Layer Protocol phase, 


must reach the Opened state. 


and the Compression Control Protocol 


Exactly one Predictor datagram is encapsulated in the PPP Information 


field, 


where the PPP Protocol field indicates type hex OOFD 
(compressed datagram). 


The maximum length of the Predictor datagram transmitted over a PPP 
link is the same as the maximum length of the Information field of a 
PPP encapsulated packet. 


Prior to compression, 
Protocol number. 
Compression is negotiated. 


the uncompressed data begins with the PPP 
This value MAY be compressed when Protocol-Field- 


PPP Link Control Protocol packets MUST NOT be send within compressed 


dat 


calles 


a. 


Predictor theory 


Predictor works by filling a guess table with values, based on the 


hash of the previous characters seen. 


the source data, 


or depending on the guess table, 
for every byte of input, 


Since we are either emitting 
we add a flag bit 
telling the decompressor if it should 

retrieve the byte from the compressed data stream, 
table. 


or the guess 


Blocking the input into groups of 8 characters means that we 


don’t have to bit-insert the compressed output - a flag byte preceeds 


every 8 bytes of compressed data. 


corresponds to one byte of reconstructed data. 


Take the source file: 


000000 
000010 
000020 
000030 


Rand 


4141 
4141 
4142 
7878 


4141 
4141 
4142 
7878 


4141 
4141 
4142 
7878 


410a 
410a 
410a 
780a 


4141 4141 4141 410a 
4141 4141 4141 410a 
4241 4241 4241 420a 


Informational 


Each bit of the flag byte 


AAAAAAA . AAAAAAA. 
AAAAAAA . AAAAAAA. 
ABABABA . BABABAB. 
XXXXXXX. 
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Compressing the above data yields the following: 


000000 6041 4141 4141 0a60 41 
000010 Oa6f 410a 4142 4142 41 
000020 420a 6078 7878 7878 Oa 
Reading the above data says: 
flag = 0x60 - 2 bytes in this blo 
Reconstructed data is: 0 
File: A 
Guess table: 
flag = 0x60 - 2 bytes in this blo 
Reconstructed data is: 0 
File: A 
Guess table: 
flag = Oxéf - 6 bytes in this blo 
Reconstructed data is: 0 
File: 
Guess table: A 
flag = Oxéf - 6 bytes in this blo 
Reconstructed data is: 0 
File: 
Guess table: A 
flag = 0x41 - 2 bytes in this blo 
Reconstructed data is: (0 
File: 
Guess table: A 
flag = 0x60 - 2 bytes in this blo 
Reconstructed data is: (0) 
File: B 
Guess table: 
flag = 0x60 - 2 bytes in this blo 
Reconstructed data is: 0 
File: x 
Guess table: 
And now, 
with a split block. 
(e.g., compressing packets), 


the memcpy are not required. 


errors, for that matter) 


41 4141 410a 6f41 
42 0a60 4241 4241 
B. 


guessed 
9° 6.7 


correctly, 


AA 
guessed 
wE 


correctly, 


AA 
guessed 
5 6 7 


ck were 
1,2 3.4 
A 
AAA 
ck were 
1234 
A 
AAA 
ck were 
1234 


correctly, 


AA 
guessed 
5 6 7 


correctly, 


AA 
guessed 
3.6: 7, 

B 


correctly, 


A 
guessed 
3:6 7 


correctly, 


AB 
guessed 
5 6 7 


ck were 
1234 
x XXX 

x 


correctly, 


x 


You can detect this situation 


that more data is required from the compressed data stream, 


are out of data 


(len in decompress is <= 0). 


and flags indicate guess table usage. 


#include <stdio.h> 
#ifdef _ STDC__ 


Rand 
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0-3, 


0-3, 
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‘AAAAA. ‘AAAAA.OA 
.OA.ABABAB. ‘BABA 
‘XXXXX. 


5 and 6. 


5 and 6. 


5 and 6. 


5 and 6. 


0 and 6. 


5 and 6. 


5 and 6 


on to the source - note that it has been modified to work 
If your data stream can’t be split within a block 
then the code dealing with "final", 


and 
(or 


by observing that the flag byte indicates 


but you 


It *is* ok if len == 0, 
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#include <stdlib.h> 


#endif 
#include <string.h> 
/* 
* pred.c -- Test program for Dave Rand’s rendition of the 


* predictor algorithm 

* Updated by: iand@labtam.labtam.oz.au (Ian Donaldson) 

* Updated by: Carsten Bormann <cabo@cs.tu-berlin.de> 

* Original : Dave Rand <dlr@bungi.com>/<dave_rand@novell.com> 
* 


/* The following hash code is the heart of the algorithm: 

* It builds a sliding hash sum of the previous 3-and-a-bit 

* characters which will be used to index the guess table. 

* A better hash function would result in additional compression, 
* at the expense of time. 

*7 
#define HASH (x) Hash = (Hash << 4) ^ (x) 


static unsigned short int Hash; 
static unsigned char GuessTable[65536]; 


static int 
compress (source, dest, len) 
unsigned char *source, *dest; 
int len; 
{ 
int i, bitmask; 
unsigned char *flagdest, flags, *orgdest; 


orgdest = dest; 

while (len) { 
flagdest = dest++; flags 
for (bitmask=1, i=0; i < 


0; /* All guess wrong initially */ 
&& len; i++, bitmask <<= 1) { 


Il œ Il 


if (GuessTable[Hash] == *source) { 

flags |= bitmask; /* Guess was right - don’t output */ 
} else { 

GuessTable[Hash] = *source; 

*dest++ = *source; /* Guess wrong, output char */ 


} 
HASH (*sourcett+) ;len--; 
} 
*flagdest = flags; 
} 
return (dest - orgdest); 


} 


static int 
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decompress(source, dest, lenp, final) 
unsigned char *source, *dest; 
int *lenp, final; 
{ 
int i, bitmask; 
unsigned char flags, *orgdest; 
int len = *lenp; 
orgdest = dest; 
while (len >= 9) { 
flags = *sourcett; 
for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) { 
if (flags & bitmask) { 


*dest = GuessTable[Hash]; /* Guess correct */ 
} else { 

GuessTable[Hash] = *source; /* Guess wrong */ 

*dest = *sourcett; /* Read from source */ 

len--; 


} 
HASH (*dest++t) ; 
} 
len--; 
} 
while (final && len) { 
flags = *sourcett; 
len--; 
for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) { 
if (flags & bitmask) { 


*dest = GuessTable[Hash]; /* Guess correct */ 
} else { 
if (!len) 
break; /* we seem to be really done -- cabo */ 
GuessTable[Hash] = *source; /* Guess wrong */ 
*dest = *sourcett; /* Read from source */ 
len--; 


} 
HASH (*dest+t+) ; 
} 
} 
*lenp = len; 
return (dest - orgdest); 
} 


#define SIZ1 8192 


static void 
compress_file(f) FILE *f; { 
char bufp[SI2Z1]; 
char bufc[SIZ1/8*9+9]; 
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int lenl, len2; 

while ((lenl = fread(bufp, 1, SIZ1, f)) > 0) { 
len2 = compress((unsigned char *)bufp, 
(unsigned char *)bufc, lenl); 
(void) fwrite(bufc, 1, len2, stdout); 


} 


static void 
decompress_file(f) FILE *f; { 
char bufp[S1I2Z1+9]; 
char bufc[SIZ1*9+9]; 
int lenl, len2, len3; 


lenl = 0; 

while ((len3 = fread(bufptlenl, 1, SIZ1, f)) > 0) { 
lenl += len3; 
len3 = lenl; 
len2 = decompress((unsigned char *)bufp, 
(unsigned char *)bufc, é&lenl, 0); 
(void) fwrite(bufc, 1, len2, stdout); 
(void) memcpy (bufp, bufptlen3-lenl, lenl); 


} 
len2 = decompress((unsigned char *)bufp, 
(unsigned char *)bufc, é&lenl, 1); 
(void) fwrite(bufc, 1, len2, stdout); 
} 


int 

main(ac, av) 
int ac; 
char** av; 


char **p = avtl; 
int dflag = 0; 


for (; --ac > 0; ptt) { 
if (!strcemp(*p, "-d") ) 
dflag = 1; 
else if (!strcemp(*p, "-")) 
(dflag?decompress_file:compress_file) (stdin); 
else { 
FILE *f = fopen(*p, "r"); 
if (!f) { 
perror (*p); 
exit (1); 


} 


(dflag?decompress_file:compress_file) (f); 
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(void) fclose(f); 
} 
} 


return (0); 


3.2. Encapsulation for Predictor type 1 


The correct encapsulation for type 1 compression is the protocol 
type, 1 bit indicating if the data is compressed or not, 15 bits of 
the uncompressed data length in octets, compressed data, and 
uncompressed CRC-16 of the two octets of unsigned length in network 
byte order, followed by the original, uncompressed data packet. 


0 i 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CCP Protocol Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| * | Uncompressed length (octets) | * is compressed flag 

tata tatatotaotatatatatatatatotatot 1 means data is compressed 

| Compressed data... | O0 means data is not compressed 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + 

| CRC - 16 | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The CCP Protocol Identifier that starts the packet is always Oxfd. 
If PPP Protocol field compression has not be negotiated, it MUST be a 
16-bit field. 


The Compressed data is the Protocol Identifier and the Info fields of 
the original PPP packet described in [1], but not the Address, 
Control, FCS, or Flag. The CCP Protocol field MAY be compressed as 
described in [1], regardless of whether the Protocol field of the CCP 
Protocol Identifier is compressed or whether PPP Protocol field 
compression has been negotiated. 


It is not required that any of the fields land on an even word 
boundary - the compressed data may be of any length. If during the 
decode procedure, the CRC-16 does not match the decoded frame, it 
means that the compress or decompress process has become 
desyncronized. This will happen as a result of a frame being lost in 
transit if LAPB is not used. In this case, a new configure-request 
must be sent, and the CCP will drop out of the open state. Upon 
receipt of the configure-ack, the predictor tables are cleared to 
zero, and compression can be resumed without data loss. 
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3.3. Encapsulation for Predictor type 2 


The correct encapsulation for type 2 compression is the protocol 
type, followed by the data stream. Within the data stream is the 
current frame length (uncompressed), compressed data, and 
uncompressed CRC-16 of the two octets of unsigned length in network 
byte order, followed by the original, uncompressed data. The data 
stream may be broken at any convenient place for encapsulation 
purposes. With type 2 encapsulation, LAPB is almost essential for 
correct delivery. 


0 i 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CCP Protocol Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| * | Uncompressed length (octets) | * is compressed flag 

tata tatatatatatatatatatatatat-tat 1 means data is compressed 

| Compressed data... | 0 means data is not compressed 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| CRC-16 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 

| * | Uncompressed length (octets) | * is compressed flag 
ta+—4+—-4t—4+-4+-4-4-4-4-4-4-4-4-4-4-4 


The CCP Protocol Identifier that starts the packet is always Oxfd. 
If PPP Protocol field compression has not be negotiated, it MUST be a 
16-bit field. 


The Compressed data is the Protocol Identifier and the Info fields of 
the original PPP packet described in [1], but not the Address, 
Control, FCS, or Flag. The CCP Protocol field MAY be compressed as 
described in [1], regardless of whether the Protocol field of the CCP 
Protocol Identifier is compressed or whether PPP Protocol field 
compression 


It is not required that any field land on an even word boundary - the 
compressed data may be of any length. If during the decode 
procedure, the CRC-16 does not match the decoded frame, it means that 
the compress or decompress process has become desyncronized. This 
will happen as a result of a frame being lost in transit if LAPB is 
not used. In this case, a new configure-request must be sent, and 
the CCP will drop out of the open state. Upon receipt of the 
configure-ack, the predictor tables are cleared to zero, and 
compression can be resumed without data loss. 
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4. Configuration Option Format 
There are no options for Predictor type one or two. 
Security Considerations 


Security issues are not discussed in this memo. 
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